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Abstract 


The  Joint  Tactical  Simulation  (JTS)  is  a  distributed,  stochastic,  entity-level,  real-time, 
interactive  simulation,  developed  by  the  Lawrence  Livermore  National  Laboratory  (LLNL).  JTS 
provides  the  user  with  a  two-dimensional  (2-D)  view  of  its  simulation  with  a  capability  to  zoom 
in  or  out.  The  U.S.  Army  Research  Laboratory  (ARL)  has  developed  a  visualization  tool  for 
viewing  JTS  in  three  dimensions.  In  support  of  this  visualization  tool,  ARL  has  developed  a 
UNIX-based,  command-line  program,  Terracon,  which  automatically  converts  a  JTS  database 
into  a  three-dimensional  (3-D)  graphics  database  for  use  with  the  visualization  tool. 
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1.  Introduction 

At  the  request  of  the  7th  U.S.  Army  Training  Center,  the  U.S.  Army  Research  Laboratory 
(ARL)  has  developed  a  visualization  tool  for  viewing  the  Joint  Tactical  Simulation  (JTS)  in  three 
dimensions.  JTS  is  a  distributed,  stochastic,  entity-level,  real-time,  interactive  simulation, 
developed  by  the  Lawrence  Livermore  National  Laboratory  (LLNL)  [1].  JTS  provides  the  user 
with  a  two-dimensional  (2-D)  view  of  the  simulation  with  a  capability  to  zoom  in  or  out.  The 
visualization  tool  runs  on  a  Silicon  Graphics,  Inc.  (SGI)  computer  platform  and  is  based  on  a 
modified  version  of  NPSNET,  a  public  domain  virtual  reality  (VR)  simulation  system  with 
networking  capabilities  developed  by  the  Naval  Postgraduate  School  (NPS)  [2].  The  visualization 
tool  provides  a  three-dimensional  (3-D)  view  of  JTS  databases,  as  well  as  Distributed  Interactive 
Simulation  (DIS)  entities  from  other  DIS-compliant  simulations.  While  the  JTS  itself  is  not  DIS 
compliant  the  JTS  entities  may  be  viewed  in  the  visualization  tool  by  the  use  of  an  ARL-developed 
communications  bridge,  the  JTS-DIS  bridge.  The  JTS-DIS  bridge  converts  JTS  network 
broadcast  entities  into  DIS-compliant  entities  and  converts  other  broadcast  DIS  entities  into  JTS 
entities. 

In  order  to  visualize  a  JTS  database  in  the  visualization  tool,  it  is  necessary  to  convert  the  JTS 
database  into  a  format  that  may  be  read  and  understood  by  the  visualization  program.  ARL  has 
developed  a  UNIX-based,  command-line  program,  Terracon,  which  automatically  converts  a  JTS 
database  into  the  Super  Viewer  (SV)  3-D  format  or  the  OpenFlight  format,  both  of  which  can  be 
displayed  in  the  visualization  tool.  The  SV  format  is  a  nonproprietary  fomiat  developed  by  SGI 
[3].  The  OpenFlight  format  is  the  property  of  MultiGen  Inc.,  and  is  used  in  this  program  under  a 
nonexclusive,  nontransferable  limited  rights  agreement  with  MultiGen  Inc.  [4]. 


2.  General 

A  JTS  database  consists  of  a  list  of  elevation  postings  (or  nodes)  that  describe  a  rectangular 
grid-based  terrain  and  information  specifying  classes  of  cultural  feature  attributes  by  type.  A  class 
feature  type  can  include  data,  such  as  material  type  and  feature  height.  In  addition,  each  instance  of 
a  cultural  feature  is  represented  by  a  data  set  that  contains  the  feature  s  type,  as  well  as  a  list  of  2-D 
coordinate  nodes  that  specify  the  feature’s  2-D  shape  and  location.  The  cultural  features  supported 
by  JTS  are  roads,  rivers,  lakes,  buildings,  vegetation  areas,  urban  areas,  and  fences  (obstacles). 

Terracon  was  developed  in  the  C  and  C++  programming  languages,  using  both  in-house 
developed  code,  as  well  as  nonproprietary  code,  to  convert  JTS  databases  to  the  SV  or  OpenFlight 
format  for  display  in  the  visualization  tool.  The  initial  reading  and  storing  into  variable  structures 
of  a  JTS  database  file  is  accomplished  by  the  use  of  code  originally  written  for  JTS  by  LLNL.  The 
conversion  of  JTS  data  into  3-D  geometry  data  is  accomplished  by  the  use  of  code  written  in-house 
at  ARL,  except  where  otherwise  noted.  The  overall  conversion  process  performed  by  Terracon 
and  examples  of  its  performance  on  sample  data  are  presented  in  the  following  sections. 

2.1  Reduction  of  Terrain  Elevation  Data.  An  average  JTS  database  may  contain  on 
the  order  of  one  million  elevation  postings.  While  this  poses  no  problems  for  JTS  itself,  it  does 
present  a  problem  for  the  visualization  of  such  a  terrain  on  lower-end  computers  with  limited 
processing  ability.  For  example,  to  represent  a  terrain  data  set  consisting  of  1,001  *  1,001 
elevations  in  a  rectangular  grid,  it  would  be  necessary  to  generate  two  million  polygons.  Using 
such  a  large  number  of  polygons  to  display  the  terrain  alone  would  make  the  visualization  tool 
practically  unusable  on  lower-end  computers  whose  capabilities  to  display  large  numbers  of 
polygons  can  be  significantly  limited.  The  inclusion  of  an  algorithm  in  the  conversion  process,  by 
which  the  number  of  polygons  used  to  represent  the  terrain  could  be  significantly  reduced,  would 
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greatly  improve  the  performance  of  the  visualization  tool  on  any  computer  on  which  it  can  be 
compiled  (see  Figure  1). 


(a)  (b) 

Figure  1.  Conceptual  Terrain  Reduction. 

Conceptual  Representation  of  Reduction  of  3-D  Terrain  Data  (a)  Before  Reduction  and  (b)  After. 


Terracon  reduces  the  original  terrain  postings  data  by  95%  and  maintains  an  acceptable 
approximation  of  the  terrain’s  geometry  by  means  of  a  public  domain  algorithm  and  in-house 
modified  code,  Scape,  made  available  by  its  authors,  Garland  and  Heckbert  [5].  Scape  uses  a 
greedy  insertion  algorithm  to  reduce  the  amount  of  original  terrain  data.  The  reduced  terrain  dataset 
is  output  as  a  triangulated  irregular  network  (TIN)  and  is  temporarily  stored  in  a  data  structure  by 
Terracon  in  preparation  for  the  incorporation  of  certain  JTS  feature  data  into  the  reduced  terrain 
data  set  (see  Figure  2). 


(a) 


(b) 


Figure  2.  Terrain  Node  Reduction. 

Representation  of  Terrain  Node  Data  (a)  Before  Reduction  and  (b)  After  Reduction  by  Use  of 

Modified  Scape  Code. 
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2.2  Incorporation  of  Feature  Data  Into  Terrain.  When  generating  a  3-D  terrain  that 
contains  cultural  features,  such  as  roads,  rivers,  lakes,  and  building  footprints,  it  is  common  to 
simply  create  a  separate  set  of  polygons  corresponding  to  the  shape  of  the  terrain  and  include  that 
set  as  a  model  separate  from  the  terrain.  The  problem  with  this  method  is  that  wherever  feature 
data  are  represented  on  the  terrain,  there  would  actually  be  two  identical  sets  of  polygons  that  are 
coincident.  When  these  coincident  polygons  are  rendered  by  a  computer,  a  strobing  or  tearing 
effect  occurs.  This  effect  is  a  result  of  a  computer’s  graphics  engine  attempting  to  render  the  two 
sets  of  polygons  at  the  same  location  and  subsequently  displaying  random,  alternating  pieces  of 
each  set.  Thus,  areas  of  coplanar,  coincident  polygons  appear  as  mottled  surfaces  that  vary  in 
appearance  as  the  viewpoint  is  changed. 

Though  the  JTS  is  a  3-D  simulation  (aside  from  its  viewing  capabilities),  JTS  databases  do  not 
contain  elevation  information  for  each  of  a  feature’s  nodes,  though  they  can  associate  a  relative 
height  of  the  feature  (i.e.,  a  building’s  height)  with  the  feature’s  type.  Cultural  features  are  either 
represented  by  a  list  of  2-D  coordinate  nodes  that  define  a  series  of  line  segments  that  form  a  closed 
area  (i.e.,  a  lake)  or  an  unclosed  area  (i.e.,  a  fence).  The  elevations  of  feature  nodes  are 
extrapolated  from  the  elevation  of  the  terrain  at  each  node’s  2-D  coordinate.  For  example,  the 
elevations  of  a  one-story  building’s  base  nodes  would  be  calculated  by  determining  the  height  of 
the  terrain  at  each  building  base  node  and  using  that  terrain  elevation  as  that  node’s  elevation. 
Visually,  this  method  of  calculating  the  elevations  of  cultural  features’  nodes  is  sufficient  for 
creating  a  2-D  bird’s-eye  view  of  the  simulation  database  just  as  the  JTS  provides.  However,  if 
the  same  method  was  used  to  generate  true  3-D  geometry  for  display,  unrealistic  looking  features 
(i.e.,  roads  on  the  sides  of  mountains)  would  be  created. 

These  problems  are  overcome  by  first  adding  road,  river,  lake,  and  building  nodes  to  the  set  of 
reduced  terrain  nodes.  Next,  any  nodes  in  the  terrain  dataset  that  are  bounded  by  a  closed-area 
feature  are  removed  and  intersecting  segments  of  the  added  features  are  divided  into  separate 
segments,  and  new  nodes  added,  until  all  intersections  are  eliminated  (see  Figure  3). 


(b) 


Figure  3.  Incorporation  of  Feature  Data. 

Example  Showing  (a)  a  Road  and  River  Section  to  be  Incorporated  Into  Terrain  and  (b)  the  Result 
After  Removing  Feature  Bounded  Nodes  and  the  Addition  of  Nodes  to  Eliminate  Feature  Segment 

Intersections. 
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In  addition  to  the  inclusion  of  these  features’  nodes  into  the  reduced  terrain  data  set,  these  same 
features  are  flattened  with  respect  to  the  terrain  by  setting  a  common  elevation  for  subsets  of  a 
feature’s  nodes.  For  example,  Terracon  determines  the  lowest  elevation  of  the  two  coordinate 
node  elevations  that  define  one  end  of  a  road  or  river  section  and  sets  both  elevations  to  this  lower 
number.  The  result  is  that  the  end  of  the  section  is  oriented  so  as  to  be  parallel  to  the  x-y 
coordinate  plane.  Because  these  section  nodes  are  actually  included  in  the  terrain  dataset,  the  result 
is  that  the  terrain  is  modified  to  include  a  flattened  area  corresponding  to  the  location  of  the  section 
ends.  In  addition,  intersections  between  road  or  river  sections  and  the  reduced  terrain  are 
determined  and  included  in  the  corresponding  section’s  boundary  data  set.  The  result  is  that  roads 
and  rivers  more  closely  follow  or  flow  across  the  terrain  (see  Figure  4). 


(a) 


(b) 


Figure  4.  Horizontal  Feature  Orientation. 

Example  Showing  Road  Geometry  Created  Using  (a)  Original  Node  Elevations  and  (b) 

Horizontally  Oriented  End  Nodes. 


2.3  Triangulation  of  the  Feature-Included  Terrain.  At  this  point  in  the  process,  the 
feature-included  terrain  data  set  created  by  the  addition  of  features’  nodes  must  be  triangulated  in 
order  to  generate  a  renderable,  polygonal  surface.  In  order  to  preserve  the  shapes  of  included 
features,  as  well  as  the  rectangular  shape  of  the  terrain,  it  is  necessary  to  use  a  triangulation 
algorithm  that  allows  the  specification  of  required  segments  in  the  final  triangulation.  For  example, 
specifying  that  the  line  segments  connecting  the  four  nodes  of  a  road  section  be  included  the  final 
triangulation  ensures  that  after  processing,  there  will  be  a  subset  of  triangular  polygons  that 
correspond  to  the  original  road  section’s  shape. 

Terracon  triangulates  the  reduced  terrain,  building,  road,  river,  and  lake  nodes  and  specified 
required  segments  by  means  of  an  algorithm  and  in-house  modified  code,  Triangle,  made  available 
for  noncommercial  work  by  its  author,  Shewchuk  [6].  The  resulting  triangulation  is  used  to 
generate  the  output  file,  which  will  contain  the  3-D  coordinate  information  describing  the  set  of 
triangular  polygons  necessary  to  render  the  new  feature-included  terrain. 

The  features  incorporated  into  the  terrain  are  now  represented  in  the  resultant  output  file  by 
subsets  of  terrain  polygons.  In  order  for  individual  features  to  be  colored  and  texture  mapped 
(apply  image  data  to  sets  of  polygons)  according  to  their  type,  it  is  necessary  to  identify  what 
subsets  of  terrain  polygons  should  be  associated  with  what  feature.  This  is  done  by  comparing 
each  terrain  polygon  in  the  final  triangulation  with  a  list  of  the  original  features’  boundaries. 
Specifically,  a  function  is  used  to  determine  if  a  terrain  polygon’s  calculated  centroid  is  bounded  by 
an  original  feature’s  closed-area  boundary. 
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As  a  terrain  polygon  may  be  bounded  by  more  than  one  type  of  closed-area  feature,  an  order  of 
precedence  is  used  to  determine  that  polygon’s  overall  type.  For  example,  if  a  terrain  polygon’s 
centroid  is  found  to  be  bounded  by  a  river  section  that  polygon  would  be  classified  as  a  river 
polygon.  However,  if  this  same  polygon  is  also  found  to  be  bounded  by  a  road  section,  the 
polygon’s  type  would  be  set  to  that  of  a  road  polygon.  In  this  particular  example,  road  polygons 
take  precedence  over  river  polygons  in  the  assumption  that  roads  will  tend  to  cross  over  rivers 
instead  of  under  them.  By  this  method,  it  is  possible  to  group  subsets  of  terrain  polygons  into 
separate  model  files  that  only  represent  roads,  rivers,  lakes,  or  building  footprints  (see  Figure  5). 


(a) 


(b) 


Figure  5.  Terrain  Triangulation. 

Example  Showing  Reduced  Terrain,  Including  Modified  Feature  Data  (a)  Before  Triangulation  and 

(b)  After. 

2.4  Construction  of  Buildings.  A  JTS  database’s  original  building  data  sets  consist  of 
node  data  that  describes  linked  segments  that  form  a  closed-boundary  area.  Making  use  of  the 
building  height  as  specified  by  its  type,  geometry  describing  walls  and  a  flat  roof  are  created.  The 
previously  flattened  terrain  corresponding  to  the  building’s  footprint  serves  as  the  building’s  floor. 
Each  converted  building  is  written  as  a  separate  model  to  the  output  file. 

2.5  Construction  of  Vegetation  and  Urban  Canopies  and  Fences.  A  JTS 

database’s  original  fence,  vegetation  area,  and  urban  area  data  consists  of  node  data  that  describe 
linked  segments.  Vegetation  and  urban  data  describe  closed-areas,  while  fences  do  not.  In  order 
that  the  generated  3D  models  of  these  features  realistically  follow  the  terrain,  nodes  are  added 
which  correspond  to  intersections  between  these  feature  segments  and  terrain  segments  defined  by 
the  final  triangulation  of  the  feature-included  terrain  data  set  (see  Figure  6). 
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(a) 


(b) 


Figure  6.  Addition  of  Terrain-Corresponding  Nodes. 

Example  Showing  (a)  Original  Area  Nodes  and  Segments  and  (b)  Terrain-Corresponding  Nodes 

and  Segments  Added. 


In  addition,  for  the  vegetation  and  urban  areas,  terrain  nodes  and  segments  bounded  by  the 
closed-area  data  are  included  in  each  area  feature’s  data  set.  By  including  these  bounded  nodes,  a 
canopy  of  polygons  may  be  created  that  mimics  the  terrain  at  the  feature  type’s  specified  height. 
Each  feature  is  written  as  a  separate  model  to  the  output  file  (see  Figures  7  and  8). 


Figure  7.  Terrain-Following  Features. 

Representation  of  How  Additional  Data  Converts  (a)  Non-Terrain-Following  Features  Into  (b) 

Terrain-Following  Features. 
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Figure  8.  Converted  Test  Database,  tinytown.flt,  Showing  Terrain-Following 

Features. 


2.6  Automatic  Texture  Mapping  of  Feature  Models.  A  JTS  database  contains 
information  about  classes  of  feature  types.  For  example,  a  specific  building’s  type  may  identify  it 
as  being  constructed  of  wood.  Based  on  a  feature’s  type,  a  generic  texture  corresponding  to  the 
type  is  specified  to  be  mapped  onto  the  object  to  add  additional  realistic  detail  to  the  final  3-D 
geometry.  Default  textures  are  used  for  features  without  a  specified  type.  Actual  texture  files  need 
not  be  present  during  the  conversion  process  (as  textures  are  only  specified  by  filename  in  the 
output  files),  but  must  be  accessible  by  the  visualization  tool  at  run-time  (see  the  appendix,  and 
Figures  8,  A-2  and  A-4). 

2.7  Performance.  As  an  indication  of  Terracon’s  performance,  the  conversion  program 
was  used  to  convert  three  different  JTS  databases  with  varying  numbers  of  terrain  postings  and 
cultural  features  on  two  different  SGI  computer  platforms:  an  SGI  Onyx  with  4  *  200  MHz 
R4400  processors  and  an  SGI  Indigo  II  Extreme  with  a  1  *  150  MHz  R4400  processor.  Because 
Terracon  does  not  make  use  of  multiple  processors,  only  a  single  central  processing  unit  (CPU) 
was  utilized  when  the  program  was  run  on  the  SGI  Onyx  system.  Specific  statistics  about  each 
database  are  listed  in  Table  1,  along  with  the  elapsed  real  time  for  each  platform.  Real  times  (actual 
CPU  times)  were  calculated  by  running  the  UNIX  command,  timex,  with  the  Terracon  executable 
and  a  JTS  database  as  arguments. 
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Table  1.  Terracon  Performance  Comparison  of  JTS  Databases. 


ITS  Database 

navy_yard.DAF 

grafenfels.DAF 

sarajevo.DAF 

Elevation  Postings 

1,002,001 

Buildings 

137 

234 

167 

Roads 

141 

4,160 

4,695 

Rivers 

1 

1,175 

2,015 

Lakes 

7 

108 

3 

Vegetation  Areas 

8 

3,047 

2,572 

Gty  Areas 

13 

134 

131 

Fences 

9 

0 

0 

Triangular  Polygons  Created 

10,893 

266,749 

550,352 

Onyx  Time  (h:m:s) 

0:0:11 

0:28:30 

1:47:57 

Indigo  Time  (h:m:s) 

0:0:15 

0:40:20 

2:22:13 

3.  Future  Developments 

While  Terracon  is  a  robust  conversion  tool  and  is  currently  being  used  by  the  7th  U.S.  Army 
Training  Center,  there  are  a  number  of  areas  in  which  this  tool  can  be  improved.  Some  of  these 
improvements  are  discussed  in  the  following  paragraphs. 

One  improvement  would  add  the  capability  to  control  the  percentage  by  which  the  original 
terrain  data  set  is  reduced.  Currently,  a  95%  reduction  is  hard-coded  into  Terracon.  Providing  the 
user  the  ability  to  set  the  percentage  of  reduction  would  enable  users  with  higher-end  computer 
platforms  to  make  use  of  higher-fidelity  3-D  terrain  databases  if  they  so  desire. 

Additional  improvements  can  also  be  made  to  the  method  by  which  buildings,  vegetation 
canopies,  and  urban  canopies  are  created.  Currently,  Terracon  does  not  process  some  building, 
vegetation,  and  urban  data  sets.  Specifically,  these  data  sets  are  not  converted  if  their  coordinate 
nodes  describe  segments  that  intersect  with  themselves  (self-intersecting  features).  This  is  more 
than  a  trivial  problem,  as  there  are  many  possible  different  cases  of  self-intersecting  features.  An 
examination  of  typical  JTS  databases  shows  that  only  a  small  fraction  of  building,  vegetation,  and 
urban  features  are  self-intersecting.  Modifying  Terracon  to  handle  these  cases  of  self-intersection 
would  remove  the  restriction  currently  set  on  users  of  the  visualization  tool  to  not  create  self- 
intersecting  features. 

Finally,  not  all  of  the  data  in  a  JTS  database  that  might  be  converted  by  Terracon  are  converted. 
The  original  work  request  for  a  conversion  program  excluded  JTS  data  that  describes  the  interior 
walls,  doors,  and  windows  of  buildings.  As  an  improvement  to  the  existing  program,  Terracon 
could  be  modified  so  that  these  data  are  converted  to  provide  more  detailed  and  accurate  building 
models. 
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4.  Conclusion 

Terracon  was  developed  to  convert  JTS  databases  to  a  3-D  format  so  that  their  contents  might 
be  viewed  in  the  visualization  tool.  It  provides  a  hands-off,  automatic  conversion  process  that 
reduces  the  original  terrain  data  set  by  95%;  flattens  and  incorporates  cultural  features,  such  as 
roads  into  the  terrain,  generates  vegetation,  urban  and  fence  models  that  realistically  flow  over  the 
terrain;  and  applies  generic  texture  maps  to  all  generated  models  by  feature  type.  The  program 
provides  reasonable  performance  as  measured  by  conversion  times  on  most  SGI  platforms.  All 
code  written  for  or  incorporated  into  Terracon  is  nonproprietary  and  can  thus  be  easily  enhanced  or 
expanded  to  meet  the  needs  of  current  and  future  users. 
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Appendix: 

Screenshots  Of  Conversions 
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Figure  A-l.  2-D  View  of  JTS  Database,  navyyard.DAF. 
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Figure  A-2.  3-D  Views  of  Terracon-Converted  JTS  Database,  navy_yard.flt. 


Figure  A-3.  2-D  View  of  JTS  Database,  sarajevo.DAF. 
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Figure  A-4.  3-D  Views  of  Terracon-Converted  JTS  Database,  sarajevo.flt 
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